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ABSTRACT 



The Naval Postgraduate School is developing a small, 
experimental, low-orbit packet radio satellite for launch in 
1995. It is the first for use by the amateur radio 
community to implement spread spectrum communications. To 
aid in designing the spacecraft's communications network, we 
have developed an object-oriented, reusable, high resolution 
simulation model, PACSIM, which: 

• fully emulates the activity of users in the network; 

• has the ability to provide information on these measures 
in several thousand different scenarios. 

We describe this satellite-user network and elucidate the 

strong interdependence of design factors. Simulation 

results are presented. Also, we critique the use of 

simulation as a decision aid for assessing the effect of 

design decisions such as data transfer rate, spacecraft 

memory allocation for store-forward and capture protocol 

among other factors . 
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I. NETWORK DESCRIPTION 



A . BACKGROUND 

The Petite Amateur Navy Satellite (PANSAT) is a small, 
low-orbit spread spectrum communications satellite scheduled 
for launch in 1995. It is designed for use by amateur radio 
operators. The spacecraft's orbit is expected to be at an 
altitude between 450-800 kilometers, at an inclination of 
93.5° and a maximum slant range of approximately 2000 km. 
Users on the ground will be provided with a view of the 
satellite between four and ten minutes in duration. The size 
of the user base is currently unknown. However, the fields of 
spread spectrum, packet radio and satellite communications are 
widely used among amateur radio operators and attention to 
this program has grown. 

1. Siimmary of session 

The spacecraft will normally be in receive mode until 
it arrives in the view of a user's ground station and acquires 
the pseudo-noise coded signal from it. This sequence is a 128 
bit stream and is transmitted by the subscriber until 
acquisition is achieved. The receiver assesses if it is 
following the sequence in synchronization with the transmitted 
signal. If not, it "slides" and "looks" again to determine 
whether it matches . 
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The coinmuni cat ions payload of PANSAT is designed for 
a central frequency of 437.25 Mhz (960 Khz bandwidth) . Uplink 
and downlink will be done within this bandwidth, with 
information relayed in bit packets. These packets are stored 
and retrieved in the spacecraft control unit's (SCU) on-board 
processor. Data storage and retrieval are accomplished using 
the operators' callsigns as references. PANSAT is intended to 
have its own address for use by the ground control station. 
Commands for the satellite are envisioned only to request 
experiment data and provide telemetry and performance 
information to the control station. 

B . HIGH-LEVEL DESCRIPTION 
1 . General 

The system consists of uncoordinated users who contend 
for access to a single channel. As shown in Figure 1 these 
users, also called subscribers, are located at ground sites 
not necessarily covered by a 
single orbit of the 
spacecraft. Due to the 

periodicity of PANSAT' s path, 
it will not be in a user's 
view during each orbit. 

As the spacecraft 
comes over the horizon, a 
subscriber will attempt 

function of PANSAT' s orbit. 




Fiofure 1 User access is a 
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cominuni cat ions windows due to the low orbit of the satellite. 
Users access the channel by locking-up, or synchronizing, with 
the satellite. When two or more subscribers simultaneously 
attempt to initiate a session with the spacecraft, there are 
two possible results: either there is a collision or one will 

capture the server. A collision results in unsuccessful 
attempts for both users and requires later scheduled 
synchronization transmission. Tagged to the end of the 
synchronization is a preamble identifying the user, followed 
by the data packet along with its routing instructions, called 
the header. 

If the message arrives at the spacecraft, the SCU 

• routes the message for the appropriate addressees ; 

• forms a queue of messages stored for the addressee ; 

• transmits, or downloads, the stored traffic after 
synchronizing with the recipient, . 

The caller then requests a disconnect and the satellite 

returns to a ready state, awaiting a new attempt for 

synchronization . 

2 . Channel Access 

As mentioned above, users are not coordinated by a 
master clock nor can they sense whether a channel is being 
accessed or in use. The only information provided is the 
starting time of the communications window. This window of 
time reflects the interval during which the spacecraft is in 
the view of a user. In other words, the low-earth orbit of 
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the view of a user. In other words, the low-earth orbit of 
the satellite provides a limited horizon on the ground. As 
this horizon, or footprint, traverses the ground, it covers 
the position occupied by a user. The period from initial 
coverage in the footprint to termination is the communications 
window . 

Due to the absence of overall network control, the 
occurrence of transmission delay and an array of other 
arbitrary factors, it is assumed that no two callers' 
synchronizing signals are initiated at the exact same time. 
However, a characteristic of this transmission-driven protocol 
is that the synchronization sequence -- the elements of which 
are called chips -- is sent iteratively until the SCU's 
receiver achieves a lock and is captured. 

If another attempt occurs such that its sequence is 
within a phase difference not exceeding the duration of a 
single chip, the SCU's receiver will be unable to distinguish 
between the signals and a collision results (Pursely, 1987, p. 
118) . A collision causes a failed attempt and another is made 
after a delay. If there is sufficient offset between two 
synchronization streams, then one will be successful, 
depending upon which bit stream is more proximal to the 
pattern expected at the spacecraft's receiver. A caller is 
made aware of an unsuccessful synchronization if during the 
time following the signal, no acknowledgement or subsequent 
message transmission is received from the satellite. 
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3 . Packet Flow 



The message generated by the user is subject to bit 
error, associated with the bit error rate identified in the 
spacecraft designers' link budget analysis. Occurrences of 
bit error, which are not independent events, may signify the 
loss or partial destruction of a packet. This is unknown to 
the engaged user. After accessing the channel, the user will 
accept a synchronization signal from the spacecraft 
communicating its acknowledgement of receipt of the user's 
packet and transmitting traffic addressed to the engaged user. 
If this is not detected by the user, a new transmission is 
generated in order to ensure receipt of the apparently lost 
traffic . 

After the subscriber transmits an identification 
preamble, the spacecraft attempts synchronization. There is no 
contention for the current user's receiver and the sequence is 
followed by all traffic stored by the spacecraft control unit. 
Finally, the subscriber follows with an acknowledgment of 
receipt of the down-linked traffic and a request for 
disconnect. The SCU recognizes this and returns to a ready 
state. If the disconnect request is not received, then the 
SCU times out and retransmits the stored traffic. If final 
acknowledgment is still not received after a specified period 
and a stipulated number of retries, the spacecraft returns to 
a ready state. 
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4 . Packet Storage and Forwarding 

This aspect of message transfer occurs in the 
spacecraft. Upon arrival of a packet at the spacecraft, it is 
stored until the SCU is accessed by the addressee. Several 
factors bear much relevance: 



• The delay in message forwarding from originator to 
addressee may range from seconds to days. 

• Message size is of arbitrary length although the maximum 
length may be fixed (Brachman, 1988, p. 20) . 

• Packet storage capacity of the SCU is finite. 

• Messages may be addressed to other individual subscribers, 
multiple users or all users. 

Due to storage constraints, as the number of users increases, 
storage may become scarce. For example, if a packet is 
addressed to a group of users, it might be beneficial to store 
single copies of messages with more explicit routing 
instructions rather than a single copy for each. 

C. NETWORK DESIGN DETAILS 

This network has associated with it several design issues. 
Channel access is influenced by the number of users with the 
spacecraft in view concurrently attempting to access the net, 
the possibility of collision, the distribution of the duration 
of the synchronizing procedure as well as the occurrence of 
bit error and resulting retransmissions of data. Data 
transfer is influenced by packet length, the occurrence of bit 
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error, propagation delay, the extent of error detection and 
correction as well as the speed of the SCO's processor. The 
store-and-forward problem is affected by the number of 
subscribers, packet routing instructions, bit packet length, 
and storage capacity. An enumeration of specific design 
questions and their associated measures of effectiveness is 
provided in the next chapter. 

1. Channel Access 

Given the absence of coordination among users, it is 
reasonable to assume that each will independently initiate 
synchronization attempts in accordance with some arrival 
process. An outline of the channel access process is shown in 
Figure 2 . 

For a situation in which a geostationary satellite is 
involved, users have continual access to the spacecraft. In 
this case, the model may achieve an equilibrium in which 
attempts to establish communications may be well represented 
by a carefully selected 

arrival process. However, 
because many users are aware 
of the time at which the 
spacecraft comes into view, 
the first attempts by each 
may be governed by a 
different timing algorithm 



Initialy, the saiefte is h an idle stale. After a subsafeer achieves a 
lock, the server transidons to a busy stale during wM 
conducts a ses^ with the current user. 




Figure 2 Contention for 

channel access. 
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than subsequent bids, depending on the occurrence of a 
success. After "arriving," the synchronization process takes 
place . 

When in the ready state, the SCU's receiver is 
continuously scanning the spreading sequence for the 
transmission of a synchronization signal. This is a 128 bit 
sequence which is transmitted until an attempt is sensed. At 
this point, the receiver compares the received pseudo-noise 
sequence with the expected 

progression as seen through the 
current sequence. If there is 
no match, then the receiver 

will shift its scanning of the 
band by a predetermined 

duration of time and compare 
again. This is continued 

Figure 3 Illustration of 
iteratively until the receiver the synchronization process . 

attains a lock. The characteristics of the clocking sequence 

of the pseudo-noise generator dictate the specific quantity of 

time elapsed during this process. 

Between initiation of the synchronizing process and 
the capture of the channel, there is a non-zero probability of 
collision. The occurrence of a collision is a function of the 
distribution of subscribers initiating simultaneous attempts 
to access the SCU and the distribution of the number of 
repetitions of the synchronizing sequence which must be 



Hie spreading sequence may be transmitted 128 times, 
if not busy, the receiver wili lock on during one of them. 


1234 

I I I I I I I I I 


128 

1 ...1 II 1 1 ...1 1 1 1 


bock will be achieved ^ 
inanyonerepethion 1 
with^ualprobabiFity. | 


^ Infacttheprobabirityis 
1 64/128, a0.5,thatthe 
1 receiver is captured during 
the first 64 tries. 
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completed to achieve lock (Woerner, 1991, p. 128) . Regardless 
of the collision event, multiple users attempting to access 
the net increases the effective noise in the RF environment. 
Increased noise causes a deterioration in the link margin and 
may give rise to increased probability of bit error in session 
transmissions . 

2. Data Transfer 

This feature of the network is affected by decisions 
regarding packet size, error detection and correction, 
acknowledging message receipt and the establishment of a half- 
or full-duplex channel. 

Decisions concerning packet length have ramifications 
throughout the operation of the network. Regarding packet 
transmissions from a subscriber or from the spacecraft, not 
only do longer packets require a greater amount of time for 
transmission but they have a greater probability of 
experiencing bit error. Furthermore, the length of packets 
impacts the SCU storage capacity. Options include 
establishing fixed message lengths, maximum message lengths 
with variable length packets, or leaving message size 
unconstrained. Each of these considerations may be viewed in 
light of the bit error rate. Because the occurrence of bit 
error is not independent among individual bits, the greater 
the size of the bit packet, the higher the probability of the 
packet incurring bit error. 
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The worst-case scenario is that any incident of bit 
error results in the loss of a packet. However, unless some 
error detection is instituted, the absence of error in the 
message header is satisfactory for a message to be received at 
the destination. This is insufficient for reliable networks 
(Tanenbaum, 1988, p. 202). To institute negative 

acknowledgements requires retransmissions and lengthens the 
span of the session. However, introduction of error 
correction such as Hamming codes lengthens the packet to more 
than three times its original length (Tanenbaum, 1988, p. 
208), and would also be very likely to have a significant 
impact on the duration of a session. 

The final aspect to 
be discussed in analyzing the 
network data transfer is the 
implementation of a full- 
duplex as opposed to a half- 
duplex channel . The two 
scenarios are depicted in 
Figures 4 and 5 . Regardless 
which channel type, 
subscribers independently 
attempt to synchronize with the spacecraft's receiver. Only 
if successful will a user be able to conduct a session with 
the SCU. The session differs conditioned on whether or not 
the channel is full- or half -duplex. 



■SCO 

dlsoonrvwcts, 
awahlna n«w 
synch ^nal. 




Sii»crfMr 
transmits 
synchronization 
signal with bit 



User transmits an ack 
for storod pactots and 
rsquasts disoonnact 






time 



Figure 4 Full duplex 
communications flow between SCU 
and subscriber . 
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In full-duplex, the subscriber's receiver must be in 
lock with the spacecraft's transmitter in order to be able to 
conduct a session. Once both caller and SCU are in 
synchronization, communicated by the user as a connection 
request and by the spacecraft as an acknowledgement, data 
exchange occurs. While receiving, acknowledging and storing 
the data transmitted by the active user, the spacecraft 
retrieves and forwards messages addressed to the active user. 
If the packets are error-free and successfully received at 
either end, then acknowledgements are dispatched and a 
disconnect occurs. However, if errors are detected then 
negative acknowledgements are sent and packets are 
retransmitted. Finally, if no acknowledgements are received 
after a time-out, then the packet is retransmitted. 

The half-duplex 
session is more involved 
because after each 
transmission, communications 
are stopped and the other 
site must synchronize in 
order to transmit 
acknowledgments or data. 

Specifically, after capturing 
the SCU and completing the 

Figure 5 Half duplex 

synchronization signal, the communications flow between SCU 

and subscriber . 

active user transmits the 
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data packet. Upon broadcasting the packets, the user ceases 
transmission and waits a period of time commensurate with the 
transmission duration and turn-around time. The SCU is 
expected to attempt synchronization and transmit an 
acknowledgement and any mail appropriately addressed. In the 
case of error-free receipt of the stored traffic, the user 
again synchronizes with the spacecraft's receiver in order to 
acknowledge the mail and request disconnect. Once more, the 
detection of bit error or occurrence of time-out will 
necessitate retransmission; however, due to the nature of 
half -duplex communications, retransmissions must be preceded 
by a synchronization stream. 

During the course of these synchronization attempts 
with the SCO's receiver, the spacecraft will need to prevent 
intervening callers' attempts to send traffic while awaiting 
the active user's synchronization to resume the session. 

3. Store-Forward 

The receipt of packets by the SCU initiates the 
process of store-and-forward . After the message arrives, it 
is routed to storage according to the callsign of the 
addressee. Packets currently in storage and addressed to the 
current user are retrieved and transmitted. This process is 
shown in Figure 6. Issues of interest include message 
processing time, the storage capacity constraint and network 
reliability . 
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The network will use 
a source routing procedure. 

There are three general cases 
involving packet routing: 
single addressee, multiple 
addressees or messages 
addressed to all users. For 
single-subscriber addressed 
packets, once a message has 
been delivered, processor storage space is made available. 
For messages addressed to multiple users, a separate listing 
must be maintained to mark deliveries in accordance with 
packet headers . These messages may be held for long periods 
of time. 

Regarding the storage constraint, as available memory 
dwindles, an auto-dump capability ought to be implemented, 
freeing space for new messages. For effective storage 
management, packets need to be prioritized in some way, 
duration of time in storage for example, so that some 
proportion of the total number of messages are deleted. This 
brings to light the matter of network accountability in an 
acknowledged connectionless service. Once the SCU accepts a 
message, it becomes responsible for delivery of that message. 
Packets which are dumped due to storage limitations restricts 
the level of network reliability. 
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Although straightforward, this communications network 
has very densely interrelated operating charcteristics . A 
challenge in modeling and simulating this system is to 
identify design considerations which may limit operation or 
which may be altered to enable improved performance. An 
enumeration of the items of interest and a discussion of the 
model follows. 
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II. ENUMERATION OF DESIGN ISSUES 



In attempting to create a 
network which performs well 
across the areas of channel 
access, communications flow 
and packet handling, several 
questions of interest have 
emerged. Designers of PANSAT 
expect that decisions in building the system show significant 
improvement of performance measures across a broad array of 
scenarios. Particularly, decisionmakers seek enhancement in 
channel access, decrease in session duration and firm 
assessment of SCU memory requirements. These concerns are 
enumerated by the following issues and partial listing of 
applicable design considerations: 

• probability of channel access as a function of maximum 
synchronization sequence length, data transfer rate, the 
number and distribution of waiting times before 
retransmission attempts; 

• session duration as a function of maximum synchronization 
sequence length, data transfer rate and maxim\im (or fixed) 
packet length; 

• SCU storage requirements as a function of maximum packet 
length and user population density. 

As may be determined from this list, there is a strong 
interdependence among the design issues and operational 
considerations. In fact, the three areas of activity, access. 




Figure 7 PANSAT Network Design 
Issues 
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flow and store-forward, 
affect one another. Channel 
access can be expected to be 
facilitated by shorter 
sessions. In turn, higher 
rates of channel access may 
cut down on variability of 

Figure 8 Influential network 
the maximum amount of SCU design factors 

memory in use. To establish 

the model as a credible decision aid, these issues must be 
formally defined, analyzed and simulated. This chapter lays 
out decision makers' questions of interest and measures used 
in making the determination. 

A. CHANNEL ACCESS 

For PANSAT's network to be successful, users must be 
furnished with reasonable opportunity to capture the server. 
This may be measured by the proportion of users obtaining a 
lock during the first attempt, and during subsequent retries. 
Capture is affected by 

• maximum number of repetitions of the synchronization 
sequence; 

• data transfer rate; 

• discipline governing retries. 

The channel access problem may be interpreted as follows. 
Given a number of callers who simultaneously have the 
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The channel access problem may be interpreted as follows. 
Given a number of callers who simultaneously have the 
satellite in view, how many attempts, on average, are required 
to be able to conduct successfully a session with the 
spacecraft. Alternately, • what proportion- of users are 
successful on the first attempt and then on each subsequent 
attempt . 

Underlying the whole channel access question is the 
concern that the system operator, the Naval Postgraduate 
School, be assured access to the server. Network design 
decisions may be implemented to enhance that prospect, but 
may be found inadequate under the best circumstances. In this 
case, other means should be developed for activation. 

1. Synchronization Discipline 

There is no feedback marking the achievement of lock 
by any transmitter's spreading code. The user receives no 
indication of success in capturing the server's receiver until 
at least after transmitting the identification preamble 
following the synchronizing sequence. Given an idle server, 
capture after the full 128 iterations of the spreading code is 
almost assured; as will be shown, the SCU is captured, on 
average, in 64 iterations. A lower cap not only reduces the 
excess time spent transmitting the spreading sequence, but in 
the event of a busy server, also allows for fewer delays in 
initiating subsequent retries. 
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2. Bit Rate 



It is obvious that an increase in data transfer rate 
will most likely shorten the duration of a session; doubling 
the bit rate may halve session lengths. Designers' interest 
in this relationship between bit rate and channel access 
reflects the notion that shortening the duration of a session 
will increase users' access to the server. Other factors are 
not specifically under the engineers' control. These include 
the effect of the number of collocated users concurrently 
desiring access or the ramifications of increased bit .error 
rate. As determined by the engineers' communications network 
link analysis, two feasible data transfer rates are 1200 and 
2400 bits per second (bps) . However, either the expected bit 
error rate may increase or the link margin may decrease for 
the higher data transmission rate (Morgan, 1989, p. 471) . The 
question is whether the higher bit rate significantly improves 
the likelihood of a user accessing the server despite 
increased probability of bit error. 

3 . Retransmission Regimen 

After transmitting the synchronization signal, 
identification preamble and bit packet, the subscriber is in 
either of two states. The user 

• is engaged in a session with the spacecraft control unit 
if the server is idle; 

• will need to retransmit the entire sequence if the server 
is busy. 
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In the event of retransmission, what should govern the 
amount of time to wait and the number of retries? From a 
network management perspective, the goal is to allow for the 
largest number of users to access the channel. This might 
encourage continual retransmissions until success is obtained. 
On the other hand, it is important to preserve some circuit 
discipline and minimize noise contributed by other users' 
transmissions for access to the channel. Resolution of this 
question will be implemented in a protocol allowing for the 
highest access rate coupled with the minimum number of 
attempts . 

B. SESSION DURATION 

In the communications flow paradigm, the spacecraft spends 
a significant proportion of time in a captured state. This is 
directly analogous to the busy server in a queueing system. 
Of interest is how the duration of these busy periods vary 
with the implementation of a full- or half-duplex channel, the 
data transmission rate, packet size, and bit error rate. 

The duration of user sessions directly impacts the number 
of users who may actually gain access to the net in a finite 
period of time. So, to a large extent the design parameters 
and questions enumerated for channel access also apply to the 
session duration problem. First and foremost is the decision 
to implement a full- or half-duplex net. In this context, 
engineers may then determine the direction to pursue regarding 
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the synchronization process, bit rate and maximum packet 
length. 

1. Duplex vs. Half -Duplex 

Nominally, the sequence of events required to ensure 
a successfully completed half-duplex session is longer and 
more complicated than that for the same session on a full- 
duplex circuit. The key concept is that all events in a half- 
duplex channel are serially arranged. In a full-duplex net, 
some of these events occur simultaneously. Recall, however, 
that the transmitted power is spread over half of the band- 
width in a full-duplex channel, because the net allows for 
simultaneous communications in both directions. Contending 
users' transmissions may contribute greater noise to the 
environment than in a half-duplex net. Sessions may be 
conducted over a circuit subject to the higher bit error rate 
resulting from the potentially noisier environment. A 
question of interest is whether the implementation of a full- 
duplex network results in significantly shorter sessions 
regardless of the bit error rate. 

2 . Packet Length 

Shorter packet lengths mean shorter sessions. Not 
only because the subscriber uplinks shorter messages, but all 
those stored for download are also shorter. Furthermore, 
shorter packets have a smaller probability of experiencing bit 
error than longer packets. This further eliminates the 



20 



occurrence of sessions extended due to retransmitting lost 
data . 

It is preferred to limit communications as little as 
possible, however. Placing too restrictive a constraint on 
packet length may impede a subscriber's utilization of the 
network. The engineers' objective is to allow for as high an 
upper bound on packet size as feasible while preserving the 
goal of minimizing session duration. 

3 . Spreading sequence and data transfer rates 

Pertaining to session duration, these two design 
issues have a similar impact as discussed regarding channel 
access. Engineers are interested in determining how much the 
synchronization sequence must be shortened to significantly 
decrease the duration of a session. Again, it is somewhat 
apparent that doubling the data transfer rate will shorten a 
typical session. But, is this enough to overcome any loss in 
the margin of the link analysis? PANSAT's designers want to 
know if doubling the data rate results in significantly 
shorter sessions despite a higher bit error rate. 

C. SCO STORAGE REQUIREMENTS 

The driving force behind PANSAT is its utility as an 
experimental platform. Engineers are concentrating on 
designing the spacecraft to establish the operability of this 
low-orbit communications network. Still, the storage of 
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packets poses a design problem. SCU memory used for packet 
storage varies with the number of users and packet size. 

It is important to consider that over the course of its 
lifetime, interest in PANSAT may grow to the extent that 
design limits on storage capacity may be flexed to the limit. 
For example, the satellite's software designers claim that the 
SCU's operating system will be altered significantly if the 
storage size exceed 500 kilobytes of data. Is this much space 
required or will this level be exceeded? Design matters here 
must show robustness over a spectrxim of resolution, 
introducing greater variability in storage levels. 

To determine what storage capacity to design for the 
spacecraft control unit's memory, engineers are interested not 
only in a specific measure such as the average or maximum 
level of storage used. Designing based upon an average does 
not reflect the range over which the running total walks. As 
packets are received and are downloaded, observing 
fluctuations in storage level will generate a mean value; the 
estimator gives no information on the proportion of 
observations which exceed this point, or the frequency with 
which they do so. Similarly, measuring the high-water mark, 
the maximum level reached by the SCU's memory, provides no 
description regarding how often this occurs. In any case, the 
measure of interest is the amount of memory in use at the time 
of the next packet's receipt. 
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Decision makers want to know the distribution of memory 
used. From a design standpoint, the principle factors in this 
density are the number of users allowed to participate in the 
net and determining the maximum packet length. These two 
parameters may be readily used in an analytical solution. 
However, the frequency with which SCU storage varies over a 
range of values is very much scenario dependent. For a given 
number of subscribers and packet size selection, designers 
want the SCU to accommodate a reasonable proportion of the 
total niimber of messages over a number of diverse scenarios. 

D. HOW A MODEL HELPS 

In summary, a partial listing of influential design 
parameters follows; 

• data transmission rate ; 

• user population and population density distribution ; 

• bit error rate ; 

• minimum, maximum and fixed packet length ; 

• synchronization attempt discipline ; 

• SCU storage capacity ; 

• full- or half-duplex communications. 

Complications arise in trying to assess the interdependency of 
these design factors and their effect on the network. With 
this level of complexity, as depicted in Figure 9, what kind 
of numbers may be generated by a model? How will the observed 
simulated activity differ from specified probability models 
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simulated activity differ from specified probability models 
applied to each question of interest? 

For the model's results 
to be credible, a high degree 
of resolution must be 
incorporated in the 
representation of network 
communications. In analyzing 
the system and creating the 
objects which will emulate 
the flow of activity, certain 
characteristics emerge which 
suggest a common-sense 
approach or analytic 
probability model both of which may resolve a design issue 
more quickly and as effectively as a simulation run. The 
model's three levels, common sense, analytic and simulation,' 
complement each other. 

For each measure of performance, obtaining expected values 
may be consistent between the probability models and the 
simulation. However, as a descriptor of performance, the 
average value falls far short. In essence, the merit behind 
thorough representation of network activity is the insight 
into system variability afforded the decision maker. This is 
where the anticipated divergence is between computer runs and 
paper or blackboard results. In any event, the working model 




Figure 9 First (solid arcs) and 
second order (hollow) effects 
are densely related. 
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major design decisions which may be further substantiated by 
a high-resolution simulation. 
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III. INTRODUCTION TO THE MODEL 



This communications network may be modeled with a great 
deal of fidelity as a complicated stochastic model implemented 
in a simulation. The simulation is written in reusable, 
object-oriented code so that other design issues may be 
explored experimentally and so that new studies can be pursued 
as scenarios are developed by PANSAT's sponsors. Accompanying 
probability models are incorporated to validate the 
simulation . 

The simulation contains user objects which act 
independently and the SCU object which stores and retrieves 
packets. The model also explicitly emulates the 
synchronization process and full conduct of a user-SCU session 
both in full- and half -duplex. After a brief outline of the 
principal objects in the model, a more detailed discussion of 
the model design follows. 

A. MODEL OBJECTS 
1. Users 

The network is activated by users attempting to 
capture the satellite. They are uniquely identified by the 
following attributes: 

• callsign, for addressing purposes ; 

• synchronization attempt process, dictating the 
interattempt waiting period and number of retries ; 
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• location, either isolated or collocated in a population 
center . 

The model accounts for these essential characteristics as well 
as the user's network activities by creating each user as an 
autonomous object. In this regard, operations of these users 
are encapsulated in a series of object methods which define 
their impact on the network, summarized in Figure 10. 

Channel access, packet flow and message handling, are 
significantly affected by subscriber actions. Successful 
synchronization causes the SCU to become busy and conduct a 
session. Subscribers generate messages. Message size and 
frequency of generation affect both the duration of the 
session as well as storage by the SCU. Transmission of the 
packet requires the passage of time. This influences the 
session duration and in turn affects other subscribers' 
ability to access the 



Subscribers 
are objects 
which fuiiy 
emuiate 
network users. 



net. A user's 
traffic receipt 
process has several 
ramifications across 
the network. 

Successful receipt of 
packets from the 
spacecraft completes 
the end-to-end packet 

Figure 10 User activity affecting the 
flow and also allows network's state includes generating 

packets and attempting net access. 




Fieids 

caiisign, iocation, 
window size ; 

Methods 
synchronizes (if 
unsuccessfui, attempts 
again), generates 
packets, transmits 
traffic to SCU, receives 
stored packets, 
provides ACK/NACK, 
requests disconnect. 
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the SCU to free storage space for future use. If packet 
receipt is obstructed by bit error, session durations become 
extended and endpoint-to-endpoint communications flow may be 
disrupted. Finally, the procedures of acknowledging and 
requesting disconnect prompt the end of a session and close 
the loop on packet flow. These essential activities were 
selected for inclusion in the model because they 

• fully describe the network activity of the users; 

• affect the state of the network in all areas, channel 
access, communications flow and packet handling; 

• preserve a high level of resolution in the model by 
reflecting actual network operation. 

2 . Spacecraft Control Unit 

The SCU object contains two sub-objects, the user 
interface and message storage area. These two entities have 
attributes and procedures which allow for fully analyzing the 
SCU and its role in the network. Figure 11 illustrates the 
relevant aspects of both the processor and storage units. 

The message processor is the user interface. As 
discussed in the network description, it drives the session 
with the active user. When the SCU object conducts a session, 
it waits for packet transmission by the active user, commands 
all packet storage and retrieval, manages any acknowledgement 
procedures and terminates the session. In short, it 
completely emulates PANSAT's network communications; 
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similar ly , the 
storage object within the 
spacecraft module mimics all 
salient features of PANSAT's 
SCU storage. Once commanded 
by the control unit, the 
storage manipulates the 
messages and identifies all 
packet addressees by 
callsign. The amount of packet storage space utilized is 
readily monitored; the value may be accessed at any time. 
These features fundamentally cover the activity of the storage 
unit in network operations . 

3 . Bit Packet 

The characteristics 
which define a unique packet 
are shown in Figure 12 . Just 
as in the actual network, the 
bit packet is generated, 
transmitted to the 
spacecraft, received, stored 
and retrieved and downlinked 
to the destination. It is 
subject to bit error at ends 
of the communications flow. Once the packet is routed to 



/ BltPactetObl^ 

bit packets are fully defined by: 
originator's callsign 
addressee's callsign (a record) 
for routing purpose, will 
flag If destined for fusers 
Idwtify group callsign or 
identities subscnberasaddee 
bit size of packet (Including header) 

time of transmission 



Figure 12 The bit packet 
object exhibits all 
characteristics of actual 
packets in the network. 




This is the Message 
Processing Object. It 
emulates ail of 
PANSATs comms. 



SCU: 

Ftehte 

storago, oitlt duration; 
Idfithoda 

drives session, receives 
traffic, synchronizes, sends 
stored traffic, STORES and 
FORWARDS traffic, 
provides ACK/NACK, 
terminates session ; 
STORAGE; 

Fields 

maximum capadty, 
directory of packets; 
Methods 

routes packets, retrieves 
packets. 



Figure 11 List of attributes 
owned and procedures carried 
out by the SCU. 
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storage, space is allocated; upon forwarding, space is 
deallocated . 

All network operations which influence the movement of bit 
packets are reflected with a high degree of fidelity in the 
model. This is essential to the model's utility in decision 
making. Properties of the model which prove crucial to its 
ability to properly imitate the network are discussed in the 
next section; these are followed by a listing of network 
features implemented in PACSIM. 

B. MODEL FIDELITY AND RESOLUTION 

To create a credible model, a number of concepts relevant 
to network analysis must be incorporated in the simulation. 
Simulation is a unique tool, allowing the decision-maker to 
view the model network operation under varying conditions. 
The model includes flexibility in a number of areas which 
impact the questions of channel access, packet storage and 
endpoint-to-endpoint connectivity. They include: 

• capturing the SCU; 

• packet generating environment; 

• occurrence of bit error; 

• geographically sensible population density distribution; 

• dynamics of a low-orbit spacecraft. 

These processes have consequences throughout the network. 
Although some assumptions are made, the idea is to minimize 
the model's dependence on them by incorporating as much of the 
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known communications structure as possible. This allows for 
substantial benefits in consistency of results across varied 
input assumptions. 

1 . Capturing the SCU 

The amount of accuracy built into this process is 
applied on three levels. Synchronization, initial attempts at 
access and subsequent retries are subprocesses which define 
the fidelity of capture. 

a. First Attempt 

When the spacecraft comes into view for a user, 
there is a non-zero probability that it is busy. The model 
allows engineers to choose the delay between the first moment 
a user has the spacecraft in view and the time the user first 
attempts synchronization. For an arbitrarily selected user, 
the first attempt at channel access may occur after: 

• an insignificantly small time interval; 

• a random period of time which is of the same distribution 
as any interattempt distribution; 

• a random interval according to a pre-arrival distribution 
which is different than that of the ensuing interattempt 
periods . 

Modeling the first attempt as any of these has varying 
advantages and disadvantages . 

Because the spacecraft comes into view at a known 
time, it is reasonable to expect that the initial attempt will 
occur within some small period of time. This is easy to 



31 



model. The case in which the first attempt follows a waiting 
period which is of the same distribution as the interarrival, 
or backoff, periods is also straightforward but not realistic. 
It is not reasonable to expect the typical user to wait some 
extended random interval prior to the first attempt. The last 
paradigm is the most realistic but difficult to model because 
selection of this unique pre-arrival distribution is 
arbitrairy . 

b. Synchronization 

An attempt to capture the idle SCU is not 
necessarily successful because the satellite's receiver 
discriminates based upon the spreading sequence, not the order 
of arrival (Pursely, 1987, p. 116). The spacecraft's receiver 
will start to correlate itself with the first subscriber's 
attempt. However, if a subsequent synchronization is more 
closely aligned with the receiver, this will capture the SCU 
first . 

If the uplinked 128 bit spreading code is not 
correlated with the satellite's expected string, the receiver 
slides one bit and checks again. The best case is achieving 
a lock without requiring retries; the worst is 128 iterations 
of the spreading code before lock. Because the user can not 
be assured of achieving a lock until all iterations are 
complete, the synchronizing protocol encourages transmission 
of the maximum number of repetitions. As discussed, a cap may 
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be placed on the maximum number of iterations of the spreading 
code to be transmitted. This level of accuracy is available 
in the model. PACSIM accounts for capturing the receiver 
before completion of the spreading sequence. Once in lock, 
the SCU beomes busy, but actual conduct of the session is 
delayed until the balance of the spreading code has been 
transmitted. If the cap has been attained, synchronization 
ceases, irrespective of whether the receiver has been 
captured . 

c. Retries 

If the first synchronization attempt is 
unsuccessful, the subscriber waits an interattempt backoff 
period. This is a random interval established by the 
communications protocol. The reason for randomness in backoff 
is to preclude multiple users from backing off in lock-step. 

Typical distributions for backoff are exponential, 
arithmetic, and geometric among others. After the random 
wait, another synchronization is attempted and the SCU will 
again be found either busy or not. The decision maker may 
select the backoff period distribution as well as the number 
of retries allowed per user. 

2. Packet Generating Environment 

To accurately reflect potential network activity , it 
is important to minimize assumptions and to implement expected 
characteristics in the model. Because packet creation and 
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routing is at the crux of the operations, it is particularly 
important to impose a high degree of fidelity in the following 
areas which comprise the packet generating environment: 

• packet generation; 

• packet sizing; 

• packet addressing. 

Specific elements of the packet generating environment 
implemented in PACSIM are listed in the next section. 

a. Packet Generation 

There are several schemes available in modeling 
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this aspect of the network. One dictates that all users 
continually have a need to enter messages into the network. 
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This will aid in simulation model validation. Users attempt 
to access the net and transmit a packet for handling by the 
SCU. This is the heaviest traffic generating paradigm. The 
circumstances for this will arise in the course of spacecraft 
operations, but may not be present in the actual network in 
equilibrium. 

More reasonably are the following approaches for 
modeling subscribers' need to communicate: 



• deterministic -- after specified intervals, a day for 
example, a generating mission arises; 

• probabilistic -- this paradigm establishes a random period 
of time between missions. These periods may be very long, 
influenced by the total user population, independent and 
memoryless; this suggests the use of a gamma distribution 
in defining inter-generation intervals; this is the 
probability distribution used in PACSIM; 

• scripted -- specified scenarios envisioned for packet 
generation ought to be implemented for analysis. 



If the user has the spacecraft in view, an attempt is made to 
establish a session and generate a packet for entry into the 
system. If the spacecraft is not in view, then the caller 
waits until the communication window opens and then proceeds 
as described above. Once the packet generating mission has 
been initialized, the issue of sizing and addressing the 
packet come into play. 

Jb. Packet Length 

PANSAT's engineers want to place as few constraints 
as possible on packet length to allow subscribers the 
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opportunity to communicate an unrestricted quantity of 
information. Because of a slow data transfer rate in the 
network and finite communications windows as well as protocol 
restrictions, a finite maximum packet length will be 
implemented. How can one best express the actual distribution 
of the packet size? 

By design, the model should be robust enough such 
that the choice of distribution will alter the face of the 
model imperceptibly. Because there are minimum and maximum 
bounds on message length, the actual packet size may be 
considered uniformly distributed between these limits. This 
covers a large proportion of the packets generated and 
accommodates enough variability that the realistic packet 
lengths are included. 

c. Packet Addressing 

By default a model may be created in which packet 
addressing is equiprobably distributed among all users. This 
is straightforward for developing a probability model to 
validate the simulation but stretches the notion of realistic 
packet addressing. 

More reasonable is the idea that some users are 
much more likely to be addressed in a packet than others. 
Superusers, such as the Naval Postgraduate School, the network 
system operator, can expect to receive a significant 
proportion of the traffic. Likewise, more packets will be 
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exchanged within geographic regions or other social groupings 
of users . Finally, the recipient of a packet may be likely to 
transmit another packet to the first message's originator. 
These packet volleys may persist for several exchanges. All 
of these are readily set in motion in the simulation and 
provide a great amount of fidelity with a minimum of 
assumptions . 

3 . Occurrence of Bit Error 

The probability of error occurring in data 
transmission is principally a function of signal-to-noise 
ratio. The derived bit error rate in the link analysis is 
0.00001 errors per bit (Panholzer, 1992, p. 3). Multiple 
users transmitting simultaneously create increased noise in 
the radio -frequency environment, thus increasing the bit error 
rate. Occurrences of bit error may be in the header, the 
information packet or both. Error in the header may cause 
loss of the entire packet; error in the information frame may 
cause a loss of data; error in both may also cause loss of the 
packet . 

At the user and spacecraft receivers, the packet is to 
be sampled for the occurrence of bit error. Because error 
does not occur independently among bits, representation of P^, 
the probability of bit error, is given by a uniform sampling 
of the bit packet. For example, a 1000 byte information 
packet, consisting of 8000 bits of data, Pg [packet ] =0 . 0800 . 
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On a round trip from user to spacecraft to addressee, the 
probability that this packet experiences bit error is 0.1536. 
This has the following implications for the network: 

• to preserve data flow, retransmissions will be required ; 

• channel access may be restricted due to extended sessions; 

• network reliability will deteriorate if the protocol does 
not ensure end-to-end communications to a certain level. 

All of these ramifications of bit error are included in the 
simulation model. 

4 . User population distribution 

Decision makers have sought to identify the potential 
user base for PANSAT in order to substantiate design 
decisions. Initial survey results showed a tremendous amount 
of enthusiasm for the program, predominantly in high 
population density, metropolitan regions. Unfortunately, 
enthusiasm in a survey does not necessarily map accurately 
into active participation in a financially capital-intensive 
network. Simulation may be the superior course of action in 
assessing network performance over various user population 
densities . 
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• orderly arrivals -- users attempt to access the net one at 
a time ; 

• stationarity -- the distribution of the number of 
attempts made is a function solely of the time interval 
investigated and is independent of when this interval 
starts ; 

• lack of after-effects -- the number of attempts in a given 
interval is independent of the number in previous and 
subsequent disjoint intervals. 



Based on the network description in chapter one, the 
first assumption is plausible. The credibility of 

stationarity is questionable when examining the behavior of 
the network in its full orbit. Some population centers are 
more dense than others. Intervals including activity in these 
user bases might differ significantly from observations of 
others. However, among collocated users, stationarity may be 
a reasonable supposition. During the period when collocated 
subscribers hold the spacecraft in view, the intensity of 
users attempting to access the network may be consistent among 
disjoint sub-intervals. The third assumption required for a 
Poisson process does not hold. 

Disjoint time intervals are not independent. All are 

tied to 



• session duration; extended sessions are highly 
interdependent and severely impede channel access. 
Reattempts add to the number in contention during 
subsequent intervals and packets for download accumulate 
in the SCU. The consequence is more extended sessions ; 

• the number of users; with a small number of collocated 
users, each successfully completed session results in 
fewer attempts to capture the SCU in future intervals. 
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This indicates some correlation between the number 
attempting channel access in one interval and the number 
in subsequent intervals . 

Within a population center, it is reasonable to assume 
orderliness and stationarity among subscribers contending for 
channel access. It is more difficult to justify all Poisson 
assumptions of stationarity, orderliness and independent 
increments for the spacecraft's complete orbit. 

5. Network Characteristics of a Low-orbit Spacecraft 

Subscribers are collocated in population centers. 
During certain orbits, the spacecraft's footprint may cover 
more than one of these regions concurrently. This reflects 
what is expected in actual operations of a low-orbit satellite 
communications system. PANSAT will have a bounded footprint 
allowing only a portion of the users access at any given time. 
Furthermore, the sinusoidal nature of its orbit creates a 
situation in which users will not necessarily have a view of 
the spacecraft for most. 

Periodicity in the spacecraft's orbit also yields 
varying window durations. A user will have the spacecraft in 
view for an interval lasting between four and ten minutes, 
depending on the position of the satellite in its orbit. 
Combined with the variability of session duration, the channel 
access problem becomes more realistic. These dynamics have 
implications throughout the network and are implemented in 
simulation . 
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C. WHAT WAS AND WHAT WAS NOT IMPLEMENTED 



To effect the level of accuracy described in the previous 
section, the following were implemented: 



• the first attempt was modeled to follow a very small 
period of time after the spacecraft comes into view of a 
population center; 

• the proportion of users selecting to attempt access during 
an orbit is input; 

• a cap on the number of synchroniation iterations is 
established as an input parameter; 

• the exponential backoff algorithm was used, but the mean 
backoff time is an input parameter; 

• the choice of the packet generating modes is available; 
the probabilistic approach makes use of a gamma 
distribution shaped by the number of users and, as with 
the deterministic mode, the rate of generation is input by 
the modeler; 

• the lifetime of packet generating missions is also 
selected by input; 

• packet length is determined by a uniform sampling of an 
interval, the upper bound for which is input, enabling 
emulation of fixed packet lengths by setting the bounds 
equal ; 

• packet addressing is divided into the proportion of 
messages to be addressed to the Naval Postgraduate School, 
a superuser, the proportion to be addressed within the 
goegraphic area, and those to be addressed to any user in 
the network; these proportions are input; 

« the bit error rate is input; 

« the number of user population centers, their locations, 
geographic size, and number of users are input; 

• finally, PANSAT's orbit periodicity, identification of 
location's views during a period, as well as minimum, 
maximum and average footprint durations are input. 
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In addition, some elements of a high-resolution representation 
of the network were not used. These include: 



• group broadcast in which a single message is routed for 
all or a group of users; 

• building a superuser object who would have the ability to 
address single messages to groups of users; 

• selecting the maximum number of synchronization retries; 

• using a sinusoidal function to determine the occurrence 
and duration of spacecraft views; 

• the ability for the model to read an input, scripted 
network scenario; 

• implementating protocol-specific, such as AX. 25 or TCP-IP, 
communications activity; 

• differentiating among modem- specific synchronization 
processes aside from the rate of achieving lock. 

The level of model accuracy has been firmly established. 
Although some elements of network activity have not been 
exactly implemented in simulation, the model has established 
a level of credibility such that solutions provide very high 
confidence guidelines for making design decisions. A list of 
verification experiments and results are presented in the next 
chapter . 
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IV. 



PACSIM VERIFICATION AND MODEL VALIDATION 



To ensure that the simulation model "operates in the way 
that the model implementer thinks it does" (Bratley, 1987, p. 
8) , PACSIM' s evolution as a simulation program has been marked 
by a process of verification. "Verification is determining 
that a simulation computer program performs as intended . . . 
[and] checks the translation of the conceptual simulation 
model (eg. flowcharts and assumptions) into a correctly 
working program." (Law, 1991, p. 299) This chapter outlines 
the techniques and procedures used in verifying PACSIM as a 
program and validating it as a model. 

A. MODULAR PROGRAMMING, DEBUGGING AND TESTING 

PACSIM is separated into more than 40 distinct modules, 
compiled individually and linked as a program. The initial 
manifestation of PACSIM featured one, two and three user 
scenarios and traced the entire process of channel access, 
session conduct and message storage and forwarding of a 
motionless spacecraft. Once a very high degree of confidence 
in the model was obtained, larger user population scenarios 
were used. Sensible output was confirmed as each of the 
following improvements and levels of resolution ware added: 

• cities -- determining if contention among users was being 
resolved properly; 
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• orbits -- ensuring that users could attempt access to the 
SCU only when the spacecraft was in view; 

• proportion of users attempting access -- checking for user 
synchronization attempts during the appropriate views; 

• packet generating environment -- confirming that each of 
the different packet generating schemes and missions had 
the correct impact on system activity; for example, the 
further the model departed from the heavy traffic 
generating scenario, both SCU storage levels and average 
session durations decreased. 



B. VARYING PARAMETERS AND SENSITIVITY TESTING 

The following is a partial list of parameters whose values 
were changed in validating PACSIM's performance: 

• number of users; 

• number of cities; 

• packet length bounds; 

• data transfer rate; 

• bit error rate; 

• proportion of users attempting access to the SCU; 

• spacecraft orbit periodicity; 

• number of views per spacecraft orbiting period; 

• full- or half -duplex sessions; 

• backoff rates; 

• the maximiim number of synchronization iterations. 

Experiments have generated a wide range of values for system 
performance measures by varying these parameter inputs . The 
results are discussed in the following chapter. Analysis 
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yielded the conclusion that varied inputs led to changes in 
not only the measures themselves but their variability as 
well . 

C. CHECKING AGAINST KNOWN SOLUTIONS 

The model was run "under simplifying assumptions for which 
its true characteristics are known (Law, 1991, p. 303)." An 
analytical model has been applied to the following issues in 
the PANSAT network; 

• establishing the average number of messages in SCU storage 
in equilibrium; 

• characterizing session durations by a distribution 
function; 

• treatment of the channel access problem as a single server 
system with no queue. 

The results provide a foundation for verifying simulation 
results . 

1 . Number of Packets in Storage 

For the analytical model of this issue, the following 
assumptions are made: 

• there are N independent, identical users; users access the 

• network no more than once an orbit ; 

• addressee selection is equiprobable among all users, that 
is P[packet is addressed to a specific user] = 1/(N-1) . 
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To make PACSIM simulate this tractable model, the following 
features wre altered: 



• the spacecraft is in view for the entire run; 

• all users are located in a very small interval; 

• sessions are modified to require a minimum amount of time 
to prevent second-order influence on the statistic of 
interest; specifically, data transfer rate is at 2400 
baud, packets are no longer than 100 bytes and a full- 
duplex channel is used; 

• the default, heavy communications traffic flow scenario is 
used; 

• addressing is uniform among all users. 



a. The Tractable Model 

The first objective is to define the distribution 
of the equilibrium number of messages being stored by the SCU 
for an arbitrarily selected user. 

For any user, there may be k messages in storage, 
for any k = 0, 1,.... The only transitions which may occur 
are as listed in Table 1 and depicted in Figure 13 . In all of 
the cases outlined in Table 1, the status of the future state 
of the mailbox is fully determined by the transition 
probabilities from the current state space. Because this is 
simple system Markovian, the probability distribution for k 
may be readily derived. Letting Tt^ represent the equilibrium 
probability that a user has k messages being stored by the 
SCU, 



Tln'= ^ ^ Ttn + — Tt. + — 7l, + — 71, + , 



N 



N 



N 



N 
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Table 1. TRANSITIONS FOR NUMBER OF USER'S MESSAGES IN SOU 


Transition 


Probability 


Explanation 


k to (k + 1) 


1/N 


P[pkt sent to i 1 a user 
other than i arrived] = 

(i/(N-i) ) ( (N-D/N) ; 






k to k 


(N-2) /N 


P[pkt not sent to i I a user 
other than i arrived] = 

( (N-2) /(N-1) )( (N-D/N) 








k to 0 


1/N 


P[i arrives] 


0 to 0 


(N-1) /N 


P[{i visits an empty mailbox} 
n {pkt not sent to i) 1 {user 
other than i arrived}] = 1/N 
+ (N-2)/N 



which may be written as 






where 7C,o is the probability of one or more messages are being 
stored. This yields two equations and two unknowns: 

tCq + ~ ^ and tCq ~ ^.,0 ~ 0 
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1/N 




(N-1)/N 



1 /^ 



(N-2)/N (N-2)/N 



(N-2)/N 



Figure 13 State space and transition probabilities for the 
number of messages in the SCU for an arbitrary user. 

these two equations yield the stationary probability that the 
user has no messages in SCU storage, tCq = 1/2 and the rest 
are as follows : 



or in general, K, the equilibrium number of messages in 
storage for an arbitrarily selected user is a geometric random 
variable with parameter p = 1/2 and k = 0, 1, .... The 

expected value is 





E[K] =-2=1,000 
P 



48 



with variance 



V[K] =-2-=2.000 
b. PACSIM Results 

Confirmation of the geometrically decaying number 
of messages stored for a user is provided in Table 3 . ?k is 
the proportion of users with K messages in SCU storage and % 
is the equilibrium probability that there are k messages being 
stored. Furthermore, the estimated expected value 

E[K] = k = 0.999 » 1.000 

Jc = 0 



Table 2 CONFIRMING THE DISTRIBUTION FOR THE NUMBER OF A 
USER'S MESSAGES IN SCU 



K 


0 


1 


2 


3 


4 


5 


6 + 


Pk 


.502 


.226 


.138 


.075 


.034 


.011 


.012 




.500 


.250 


.125 


.063 


.031 


.016 


.015 



and the estimated variance 

= S[K^] - i^[ic\)^ = 2.926 - 0.998 = 1.928 » 2.000 

compare very favorably with the analytical result. 

2. Expected Session Duration 

To verify the expected session duration, sessions 
extended due to message retransmissions should be eliminated 
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from PACSIM' s outcomes. 


The following simulation features 


were altered to provide 


a scenario for verifying session 



duration distribution: 



• bit error rate was 


reduced to zero, precluding the 



occurrence of bit error and any retransmissions; 

• all other elements of PACSIM were implemented in the full- 
duplex communications channel scheme. 

a . Tractable Model 



event duration 

balance of spreading code uniform random 



identification preamble 


fixed 


user message upload 


uniform random, given 
a need to generate 


SCU acknowledgement 


fixed 


user retransmissions 


uniform random, given 
bit error occurrence 


SCU message download 


geometric number of 
uniform random periods 


user acknowledgement 


fixed 


SCU retransmissions 


uniform random, given 
bit error occurrence 



2 Enumeration of a session as a series of independent 
events . 

The full duplex session is a series of random and 
fixed length subevents, enumerated in the box above. It is a 
sequence of fixed values and random variables. The expected 
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duration of the session, S^, is the sum of the expected values 
of the lengths of the subevents. The computation of these 
values are listed below. 



event 

balance of spreading code 
identification preamble 
user message upload 

SCU acknowledgement 
SCU message download 

user acknowledgement 



expected duration 

E [synchronization duration] 
constant 

E[size of message in bits] 
X transmission rate 

constant 

E [number of messages stored] 
X E[size of message] 

X transmission rate 

constant 



3 Listing of expected values of session subevents . 



b. PACSIM Result 

Computing the time required for downloading 
messages from the SCU invoked Wald's equation. The expected 
amount of data for transfer in equilibrium is the expected 
niimber of messages for download multiplied by the expected 
value of the size of these messages. The expected size of the 
messages is based upon the ass^amed uniform distribution for 
message length. Determining the expectation of session 
durations provides insight into error-free performance of the 
network. This result has direct ramifications for treatment 
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of the tractable model as a queuing system, as will be shown 
in the next section. As can be seen in Table 3 , all session 
durations observed in PACSIM are within two percent of the 
tractable model's result. 



Table 3. COMPARING EXPECTED AND OBSERVED SESSION LENGTHS 


Communications Channel Settings 


Analytical 


Observed 


1200 Baud, 2Kbyte Maximum Length 


15.47 


15.63 


2400 Baud, 2Kbyte Maximum Length 


7.57 


7.45 


1200 Baud 1Kbyte Maximum Length 


8.13 


7.96 


1200 Baud, 1Kbyte Fixed Length 


14.13 


14.33 



3 . Channel Access as a Queueing Problem 

For a tractable queuing model to be simulated the 
following factors were implemented: 



• users access attempts were distributed as Poisson 
arrivals ; 

• user synchronization attempts are sure events; 

• there are no population centers, the spacecraft is in view 
for the entire run, with the footprint covering all users; 

• all other elements of a full-duplex system were used to 
emulate the M/G/1 queue. 

a. Tractable Model 

PANSAT's engineers want users to have ready access to 
the network. Because there is only one channel for conducting 
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sessions and users must synchronize with an idle SCU to 
capture it, the channel access problem may be viewed as a 
queueing problem. Specifically, channel access occurs when 
the server is idle. The probability that the SCU is idle, 

= 1 - 

_ ^ _ Ejsession duration] 

E [interattempt interval] 

- 1 

B[T,] 

where X is the rate of users attempting to access the SCU and 
|i. is the reciprocal of the mean session duration. S^ is the 
session duration, and is the interattempt interval. To 
increase channel access, engineers will seek to shorten 
session length or increase backoff periods. 
b. PACSIM Results 

These verification experiments situated between 50 
and 400 users randomly over a 5500 second orbit. Because 
Poisson arrivals see time averages, the ratio of orbit 
duration to number of users yielded the mean interattempt 
interval. In Table 4, P^die reflects the tractable model's 
solution, while Pobs/ the proportion of users accessing on the 
first attempt, is given in the bottom row. The observations 
confirm results of the tractable model. This further verifies 
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the model as an accurate representation of PANSAT's 
communications network. 



Table 4. FIRST ATTEMPT CHANNEL ACCESS AS A QUEUING SYSTEM 


Number of Users 


50 


100 


150 


200 


300 


400 


E[SJ 


8.38 


8.27 


8.14 


8.25 


8.28 


8.38 


E[TJ 


110.0 


55.0 


36.6 


27.5 


18.3 


13.8 


^idle 


.924 


.850 


.778 


.700 


.548 


.391 ' 


p 

^ ob& 


.985 


.843 


.776 


.703 


.572 


.398 
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V. PACSIM RESULTS 



A. DATA COLLECTION 

PACSIM ran nearly 200 different scenarios to explore the 
design questions enumerated in Chapter II. All observations 
were recorded during steady state in order to evaluate the 
system's long-run behavior. Session duration and channel 
access observations were measured at the completion of 
transactions while SCU memory observations were taken when 
messages were being received by the SCU. The following 
experiments were run: 

• measuring the quantity of SCU storage used with a 1000 and 
2000 byte maximum message length while increasing the 
number and population density of subscribers; 

• comparing half-duplex channel and full-duplex channel 
session durations, at a data transmission rate of 1200 
baud under varying bit error rates; 

• comparing full-duplex session durations at data 
transmission rates of 1200 and 2400 baud under varying bit 
error rates; 

• measuring session durations with maximum message lengths 
of 1000, 2000 and 4000 bytes; 

• measuring session durations with the maximum number of 
synchronization sequence repetitions set at 128, 96 and 64 
iterations ; 

• identifying the rate of channel access at data transfer 
rates of 1200 and 2400 baud in a full-duplex circuit; 

• comparing the rate of channel access while varying 
exponential backoff rates of 15, 30, 45 and 60 seconds; - 
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identifying the rate of channel access while varying the 
maximum number of synchronization sequence iterations 
among 128, 96 and 64. 



B. sen storage 

PANSAT's designers sensed that an increased number of 
users and larger maximum message sizes require a greater 
quantity of SCU storage. PACSIM confirmed these ideas and 
provided further insight into this design issue. Figure 14 
summarizes the conclusions as follows: 



Average Quantity of SCU Storage Used 




Number of Users 

Figure 14 Average amount of SCU storage used as a 
function of user population and maximum message length. 



• in a heavy message traffic scenario and 2000 byte maximum 
message length, the initial 500 kilobyte memory threshhold 
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set by the communications designers becomes an issue when 
there are more than 300 users in the network; the envelope 
is pushed further out for the 1000 byte message limit; 



• variability in the quantity of memory used increases with 
increased user population density; all experiments used 
four population centers -- increased channel contention is 
associated with a decreased rate of access, creating an 
opportunity for messages to acc\jmulate in storage; 

• for the 2000 byte maximum message length, memory usage 
increases superlinearly with the number of users; this 
corroborates the idea that channel access is linked to SCU 
memory usage . 



This measure reflects only one scenario for network user 
activity. Observations ought to be made when 



• message generation is less intense; 

• users exercise the option not to access the SCU ; 

• a greater proportion of messages are addressed to 
superusers . 



C. SESSION DURATION 

Efforts to shorten session lengths and increase 
communications duty cycles are concentrated on shifting from 
a half- to full-duplex circuit, increasing bit rate, 
shortening maximum message length and truncating the 
synchronization process. These sessions were run under the 
heavy message generating environment, in which users uploaded 
a message and, on average, downloaded one message. 
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1. Full-Duplex vs Half -Duplex 

Originally, PANSAT was to utilize a half-duplex 
communications circuit. When the decision was made to focus 
engineering efforts on a full-duplex channel, shorter sessions 
were expected to occur. PACSIM revealed several other 
ramifications of this design decision, as shown in Figure 15: 



Session Duration vs Bit Error Rate 




Figure 15 Comparison of full- and half -duplex channel 
average session duration as a function of bit error rate. 



• full-duplex is very robust against increases in bit error 
rate; 

• full-duplex sessions have a significantly smaller rate of 
increase in duration as bit error increases; 

• due to a greater number of prolonged sessions, half-duplex 
experiences more variability as bit error increases; 
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• on average, full-duplex sessions are shorter, even at bit 
error rates exceeding three times that of half-duplex 
sessions . 

2. 1200 Baud vs 2400 Baud 

Developing PACSIM gave rise to discussions on the 
effectiveness of a half-duplex circuit. Once engineers 
started thinking in terms of operability of the network, the 
next step was to consider increasing the data rate. Figure 16 
depicts the obvious improvement in shortening the average 
session. Additionally, the following conclusions may be 
drawn : 



Average Session Duration vs Bit Error Rate 




Figure 16 Comparing effects of 1200 baud and 2400 baud 
full-duplex channels on average session duration as a 
function of bit error. 
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• 2400 baud communications are even more robust against bit 
error than the 1200 baud data transmission rate; 

• increases in session duration are almost insignificant 
even at a bit error rate four times the bit error rate 
assumed in the link analysis; 

• if the assumed link margin remains constant, the 2400 baud 
circuit outperforms the 1200 baud circuit at a signal to 
noise ratio which allows for quadruple the bit error rate. 

3 . Packet Length 



Session Duration, Varying Maximum Packet Length 




Figure 17 Comparison of session durations using maximum 
message length as the parameter. 



Engineers expect that restricting the maximum length 
of messages requires less transmission time and yields shorter 
sessions. In addition, longer messages have a greater 
probability of incurring bit error which extends sessions due 
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to retransmissions. PACSIM substantiates these notions, as 
shown in Figure 17; other conclusions include: 



• 75 percent of sessions exchanging messages limited to 1000 
bytes require fewer than 25 seconds; on the other hand, 50 
percent of the 2000 byte message exchanges and 75 percent 
of the 4000 byte transfers exceed 25 seconds; 

• larger messages for transfer yield much more variability 
in session duration; 

• average session duration under greater maximum message 
lengths shows significant increase, but provides little 
insight into their distributions . 



In lighter message generating schemes or under higher data 
tranfer rates, differences may be less pronounced. 

4. Synchronization Protocol 



Session Length vs Synch Protoc 




Max Number of Synch Sequence Iterations 



Fignre 18 Session duration 
distributions as a function 
of synchronization protocol. 



Session Duration Distribution 




Figure .19 Session duration 
density functions using the 
synchronization parameter . 
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Figures 18 and 19 depict the distribution of session 
durations while vairying the maximum number of synchronization 
iterations. The following conclusions may be drawn: 



• because of the relatively short duration of this process, 
varying the synchronization protocol has little impact on 
the duration of sessions; 

• there is no significant difference in session duration 
even if the maximum number of synchronization iterations 
is cut in half. 



If the primary purpose of altering synchronization protocol is 
to shorten sessions, there is nothing to be gained as shown by 
the insignificant difference in results. 

D. CHA14NEL ACCESS 

As discussed, design decisions with respect to channel 
access revolve around the following issues: 

• the likelihood that the Naval Postgraduate School will be 
able to access the SCU unimpeded; 

• reduction in the number- of attempts users make to access 
the spacecraft -- with each try, more noise is created on 
the channel ; 

• what proportion of users can expect to access the 
spacecraft . 

The engineers can improve overall channel access by shortening 
the duration of sessions or increasing the interval between 
users attempt at capturing the SCU. Specifically, PACSIM ran 
scenarios measuring channel access against changes in bit 
rate, backoff rate and synchronization protocol. 
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1. Bit Rate 



Figure 20 depicts channel access as a function of data 
transfer rate. It has been shown that an increase in data 
rate significantly shortens session duration. Of particular 
note : 



Proportion of Users Accessing SCU 
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Figure 20 Probability of successful channel access for a 
given attempt as a function of data transfer rate. 



• even at three times the bit error rate, channel access is 
significantly better in a 2400 baud circuit than one at 
1200 bits per second; 

» at 2400 bits per second, overall channel access is 90 
percent successful after eight attempts, while this level 
of success is attained after 14 tries in a 1200 baud net. 



63 



2. Backoff Rate 



According to the analytical result for this issue, as 
the interattempt period is increased, the rate of channel 
access improves. This experiment used a half-duplex net at 
1200 bits per second and a bit error rate of lOE-6. The 
average session duration for this scenario is 30 seconds. 
PACSIM shows this improved channel access, but in addition, it 
is evident that: 



Proportion of Users Accessing SCU 



BACKOFF RATE 




T 1 1 1 1 1 T 

2 4 6 8 10 12 14 

Number of Attempts 



Figure 21 Probability of successful channel access for a 
given attempt as a function of backoff rate. 



* there is no significant difference in successful first 
attempts ; 
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• session duration creates an upper bound on the success of 
retries ; 

• a backoff protocol in which users continually retry at 
intervals much shorter than the expected session length 
show poor rates of success . 

3. Synchronization Protocol 

PACSIM shows that 
altering the synchronization 
protocol has no significant 
effect on channel access. 

This further shows the point 
that session duration drives 
channel access . Even though 
the synchronization sequence 
was truncated to the point at 
which the probability of 
capturing the SCU was one- 
half of the 128 iteration 

process, success rates changed insignificantly. 



Portion of Users Accessing SCU 




Number of Attempts 

Figure 22 Probability of 

channel access as a function of 
synchronization protocol. 
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VI. SUMMARY AND CONCLUSION 



A. SPACECRAFT NETWORK DESIGN 

PANSAT's engineers are designing a satellite 
communications network to operate in an environment 
characterized by uncertainty. From PANSAT's onset, designers 
were developing a half-duplex, 1200 baud, store-forward system 
to accommodate: 

• a user base unknown in number, location and population 
distribution; 

• random network activity; 

• arbitrary message generating and addressing; 

• impediments to connectivity such as the occurrence of bit 
error or an inability to capture the SCU. 

The goal was to design a functional spacecraft for this highly 
unpredictable communications flow. The first step was to 
identify PANSAT's operational characteristics. 

By establishing a paradigm of network activity , engineers 
were able to concentrate on operations despite the random 
environment. We specified channel access, communications flow 
and SCU storage as the fundamental network elements. This 
highlights the simplicity of the communications network but 
provides little insight into the strong interdependence of 
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design issues and fails to reflect the extensive impact of 
uncertainty on operability. 

Figure 23 summarizes the 
nominal flow of information 
from users to the SCU and 
back to users. Nodes signify 
concurrent network activity, 
arcs depict the flow of data. 

User activity, the source of 
the data flow is subject to 
the uncertain, bursty, non-stationary nature of communications 
networks. What happens to the flow of messages when the 
number of users varies, network activity changes, or message 
addressing is altered? System performance becomes entirely 
scenario dependent. Flow from preceding states determines the 
nature of communications at subsequent points. Successful 
spacecraft network design takes these features into account. 

B. PACSIM'S DEVELOPMENT 

Once the network's underlying complexity was established, 
PACSIM was developed to emulate the system's communications 
and to provide a basis for comparing design decisions among 
different scenarios. "When a simulation model and its results 
are accepted by the . . . client as being valid, and are used as 
an aid in making decisions, we call the model credible . " Law 
and Kelton provide a methodology for establishing model 




Fifirure 23 Flow of information 



through the PANSAT network. 
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credibility (Law, 1991, pp. 299-310). The following list 
documents the construction of PACSIM as a decision aid. 



• Interaction with design team: When PACSIM was initially 

developed, the engineers' focus was not on operational 
issues, much less what the model was going to provide. As 
results emerged which confirmed and expanded on decision 
makers' notions, their interest and involvement in PACSIM 
were enhanced. Decision makers provided input on 
treatment of bit error, flexibility in packet generating 
and user selectivity in channel access. These were 
incorporated in the simulation program, further 
strengthening its validity. 

• Structured walk-through: A walk-through document 

specifying the essential elements of the network and 
outlining all network activity was presented to the 
spacecraft project's principle investigator, project lead 
and systems engineer. The meeting resulted in 

confirmation of model assumptions, awareness of network 
activity and guidance for PACSIM' s development. 

• Conversations with system "experts": In addition to over 

250 hours of meetings with PANSAT's engineers, nearly 400 
hours were spent researching, discussing and studying 
network communications. Before programming, an extensive 
analysis of network design indicated the need to reassess 
the development of the 1200 baud, half -duplex system. 

• Existing theory; There is a voluminous amount of 
literature available on packet communications. Queuing 
theory applications provided strong background in 
identifying the stochastic nature of a network and 
prompted PACSIM' s verification. 

• Experience/Intuition ; PACSIM pre-dates the network it is 
modeling; in addition, PANSAT will be a unique system. 
The foundation and fidelity of the model is backed with 
over 75 years of spacecraft, satellite and communications 
network design experience of the engineering team. 



C. EVALUATING PACSIM AS A DECISION AID 

The crux of this issue is credibility. According to 
Fossett, et al . , the level of confidence in a simulation model 
is bolstered by its ability to: 
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• reflect and take as input important features of the system 
being analyzed and its environment; 

• produce results that make sense; 

• minimize discrepancies between results and real-world 
observations (Fossett, 1991, p. 714) . 

The first two points have been covered in Chapters III and V. 
This last point is very difficult to address PANSAT's network 
is both unique and not yet in existence. Instead, the 
following questions may apply in evaluating PACSIM as a 
decision aid for this project: 

• why conduct a simulation study? 

• what is the decision-making environment? 

a. Simulation Study 

Reasons for using simulation as a decision aid is 

based on: 

• characteristics of performance measures; 

• treatment of assumptions; 

• number of scenarios to consider; 

• complexity of PANSAT operations; 

• design team's confidence in PACSIM. 

PANSAT performance measures are highly non- 
deterministic and have no applicable data for analysis. 
Examination required a model which incorporates the 
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interdependent design issues and factors as well as the random 
features. The study is particularly suited for the use of an 
object-oriented program to specify the behavior and attributes 
of important network features . 

The input data and distributions selected have been 
previously substantiated. Packet length is the only random 
input which may not duplicate the real-world size 
distribution; the use of a uniform random variable provides 
enough variance to cover a large range of values within the 
established bounds. Proper imitation of message generating 
and addressing is arbitrary. A goal is to provide the 
flexibility to balance assumptions with the ability to alter 
the scenarios. In order to augment engineers' confidence in 
the model, the impact of probabilistic assumptions was 
minimized . 

Operation of PANSAT's communications network will 
be carried out in a multitude of environments. Features 
include varying numbers, locations and activities of users, 
noise-induced bit error and spacecraft orbital 
characteristics. Some features may complement each others' 
effect on operability while others may be neutral or opposite 
in their influence. The outcome of a combination of any two 
alterations may be anticipated. Network performance under 
several features' changes is much less intuitive and requires 
experimentation through simulation. 
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Finally, the network's complexity and the model's 
crediblity make PACSIM a valued tool. Identifying the nature 
of PANSAT operations, confirming and measuring the design 
team's intuitive appraisals, providing meaning to performance 
variability, and elucidating previously unrecognized system 
characteristics have strengthened the engineers' ability to 
make design decisions. Specific inprovements in the decision 
making environment are presented in the next section. 

Jb. Decision Making Environment 

The decision makers are engineers with vast 
experience in space systems. Conclusions based on their 
intuition benefit from a working knowledge of PANSAT' s design 
issues. PACSIM' s first step toward credibility was 
confirmation of the intuitive assessments: 

• a larger number of users leads to increased SCU memory 
requirements ; 

• shifting from half-duplex to full-duplex or increasing the 
data transfer rate shortens sessions. 

The next step was to provide an understanding of variability 
in design issues: 

• increased contention for the SCU yields increased 
frequency of extended sessions and larger swings in SCU 
memory used; 

• longer messages not only increase session durations but 
experience greater variability in session duration due to 
retransmission requirements. 
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This also allowed for discussions of significant differences 
between performance measures for different designs. Finally, 
PACSIM has brought to light several issues which make it a 
useful tool for satellite network design and analysis: 



• Multiple attempts are required to obtain a reasonable 
chance of accessing the SCU. If the Naval Postgraduate 
School ground control center wants to be assured of 
access, some other means, such as secondary frequency or 
coded access, will need to be implemented. 

• Network design issues and factors are very densely 
interrelated. Session duration was expected to have a 
strong effect on all areas of communications flow. 
However, in a heavy traffic scenario, it has emerged over 
the course of experiments to be the driving force behind 
channel access and SCU utilization. 

• Efforts to shorten session duration by improvements in 
effective data rate make the network more robust against 
bit error. 



At this point in PANSAT's development, the insight 
into and measurements of characteristic network performance 
under various design decisions and operating scenarios cannot 
be obtained anywhere else. PACSIM is not a panacea, however. 
Numerical results are very much driven by scenario and cannot 
be extrapolated or predicted when applied to others. This is 
the reason for providing multiple levels of resolution to the 
model. Unfortunately, there is no way to ascertain whether 
enough reality has been implemented or if the correct 
scenarios have been incorporated in the simulation. It is 
difficult enough to forecast the utilization of a system which 
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has been operated previously. PANSAT will be the first of its 
kind . 

In any event, PACSIM provides a structure to analyzing the 
potential operating environment of PANSAT and a means of 
assessing improvements and degradations based upon design 
decisions. This tool was not previously available to the 
design team. A model is a foundation and sets the tone for 
building a successful network. PACSIM provides a window on 
previously unforeseen communications and allows the engineers 
to make more informed decisions. 
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